[00:18.160 --> 00:22.400]  Hello everyone, Arthur Packett here. We have a pre-recorded video for you.
[00:22.540 --> 00:28.240]  It's an intro to Velociraptor. This is about a 40-minute presentation. We hope you enjoy,
[00:28.240 --> 00:32.340]  and if you have any questions, please feel free to direct them to the workshop track one
[00:32.340 --> 00:37.180]  or the Recon Discord server for more immediate answers. We hope you enjoy.
[00:40.640 --> 00:46.980]  ...video to demonstrate how to install Velociraptor, and we'll just do a quick guided
[00:46.980 --> 00:56.760]  tour through the Velociraptor features, and have a quick introduction to this new DFIR tool. I mean,
[00:56.760 --> 01:02.460]  you might have heard of Velociraptor before, and in this video we will show how to install it,
[01:02.460 --> 01:09.380]  and we'll just do a quick demonstration. So I'm going to start off by... you can see my desktop.
[01:09.380 --> 01:16.960]  This is a typical Windows system, and I'm going to show you how to install it from scratch in a
[01:16.960 --> 01:23.860]  little bit, how to actually use it in real DFIR work. So the first thing that I'll do is I'm just
[01:23.860 --> 01:33.440]  going to go to the GitHub page, and I'm just going to search for a GitHub page for Velociraptor,
[01:34.000 --> 01:41.860]  and download all the releases. I'm going to show you how to install Velociraptor in the cloud,
[01:41.860 --> 01:47.000]  on a cloud platform. So the first thing I'll do is I'll download the releases.
[01:47.360 --> 01:55.600]  I'm going to have a server which will run on Linux, so I'm going to need to download the Linux
[01:56.180 --> 02:03.280]  binary. I'm also going to run the Windows executable on Windows, so I'm going to need
[02:03.280 --> 02:10.860]  to download the Windows binary. And also, finally, I'm going to need to download the source code,
[02:10.860 --> 02:17.960]  so I can show you guys how to build an MSI installer. So once I download these binaries,
[02:17.960 --> 02:26.220]  I'm going to open a new shell, and I'm just going to run it as administrator,
[02:26.980 --> 02:37.120]  so I can install the relevant MSIs. And since I just downloaded it into the downloads directory,
[02:37.120 --> 02:51.480]  I'm just going to change directory to that, like downloads. And if I do a dir, you can see the
[02:51.480 --> 02:57.260]  binaries that I've just downloaded. Okay, great. So the first thing that we need to do is create
[02:58.860 --> 03:06.200]  a configuration file in which we can deploy on the server. I'm going to create the configuration
[03:06.200 --> 03:12.320]  file on the Windows machine, and then I'm going to push it out into the server, create a Debian
[03:12.320 --> 03:19.800]  package, and push it to a Debian server in the cloud. So first thing I will do is I will generate
[03:20.200 --> 03:28.100]  a configuration file using the configuration wizard. I'm going to use the dash i flag,
[03:28.100 --> 03:33.580]  which is the interactive wizard, which will help me generate the configuration.
[03:35.580 --> 03:42.060]  So it goes off and it will ask me some questions about what exactly, what type of deployment I want
[03:42.060 --> 03:46.980]  to use, and it will actually create configuration for that. I'll start off, I'm going to be running
[03:46.980 --> 03:54.020]  it on a Debian machine, so I'll choose a Linux server. File based data store is usually the
[03:54.020 --> 04:02.800]  simplest, and this is the directory that I'm going to store all the files in. In this particular
[04:02.800 --> 04:07.340]  example, we're going to create a Let's Encrypt certificate automatically, so it will create
[04:07.900 --> 04:14.320]  an SSL certificate without any further intervention, and will also authenticate with
[04:14.880 --> 04:20.780]  standard usernames and passwords. So this is the second option, and I'm going to use one of my
[04:21.440 --> 04:30.400]  VM machines, training VMs, and this will be the domain name for the training VM. So because we
[04:30.400 --> 04:38.220]  want to create an SSL certificate, we're going to need DNS to be properly set up.
[04:38.720 --> 04:43.860]  So we're going to use a real DNS name, and Velociraptor has this really useful feature
[04:43.860 --> 04:50.700]  where it will actually update dynamic DNS by itself, without us doing anything at all. So
[04:50.700 --> 04:56.160]  if we use Google Domains for the DynDNS, it will be able to go out and update it. And over here,
[04:56.160 --> 05:06.400]  I've got the credentials for that, which you can get from the dynamic DNS settings of the
[05:06.400 --> 05:15.920]  Google Domains. So I just literally copied them into the prompt here.
[05:17.100 --> 05:22.780]  And then it will ask me to create a new user. This is the initial administrative user that
[05:22.780 --> 05:30.360]  will be created when the service installs. So I'm going to just create a new user and give it
[05:31.660 --> 05:38.600]  a password here, and then just press enter. It will generate some keys,
[05:38.600 --> 05:43.720]  finish configuring it, and you can see that it created a server config and a client config.
[05:43.720 --> 05:49.060]  If I have a look at the files, then we have the server configuration, and then the client
[05:49.060 --> 05:54.240]  configuration, which contain the keys, the key material, and all the configuration.
[05:55.080 --> 06:05.120]  So the next step is simply to create a server Debian package using that configuration. So we're
[06:05.120 --> 06:11.520]  going to run Velociraptor again and tell it to use the server configuration and Debian
[06:13.620 --> 06:18.880]  server. So we're just asking it to create a Debian package for the server.
[06:20.060 --> 06:27.520]  If we just try to do this now, then it will say, I don't actually have a Linux binary,
[06:27.520 --> 06:32.640]  so you're running a Windows binary and you're asking me to build a Debian package, so I need
[06:32.640 --> 06:39.160]  the Linux binary as well. So in this scenario, we're going to need to give it the Linux binary
[06:39.160 --> 06:48.440]  to actually package as well. So we do that, and it will actually build us a Debian package. Let's
[06:48.440 --> 06:54.680]  have a look. And we can see that there is a Debian package here that contains the configuration
[06:54.680 --> 07:00.360]  embedded with it and all the startup scripts and it's all the service configuration. So all we have
[07:00.360 --> 07:07.680]  to really do is now just push that to our cloud endpoint and then start it. So I'm just going to
[07:07.680 --> 07:18.940]  scp it to my cloud machine and over here I've got my IP address of my cloud machine
[07:22.900 --> 07:31.280]  and it will just copy the Debian package over there.
[07:32.640 --> 07:36.800]  So now I will ssh to that machine and install it.
[07:41.020 --> 07:45.740]  Okay, and if we have a look at my home directory, there is the Debian package there.
[07:46.260 --> 07:55.660]  So I just install it with the package and it's going to head and install the service
[07:55.660 --> 08:01.240]  and create it. So it's already pre-configured to start and it should just work,
[08:01.240 --> 08:06.540]  should bring up the service. I can check the service is up, service
[08:14.840 --> 08:23.680]  status, and it shows me green, active, running, and it's all ready to go. So now if I go to that
[08:23.680 --> 08:38.260]  with HTTPS, vm1.training.velocidex.com, then I should be able to log in with the username and
[08:38.260 --> 08:44.720]  password that I gave it before in the configuration file. So now we have a Velociraptor server set up.
[08:44.860 --> 08:52.280]  It only takes a minute. You can see down here the version and this is the GUI. This is great,
[08:52.280 --> 08:56.120]  so that's the server, but we still don't have any clients attached to it
[08:56.120 --> 09:00.820]  because we haven't really deployed the client side of it. So now I'm going to show you how to
[09:00.820 --> 09:09.260]  create an MSI for being able to deploy on the Windows platform. So let me get out of there.
[09:10.800 --> 09:18.880]  So we'll go back to our downloads that we had here. And to build an MSI, we use a tool called
[09:18.880 --> 09:26.700]  Wix, which is a typical MSI framework build framework. And it's very easy to do.
[09:26.940 --> 09:33.420]  Let me just open the source code, which we downloaded from the GitHub page. And in the
[09:33.420 --> 09:39.620]  docs directory, you will find a directory called Wix. And this directory contains all the scripts
[09:39.620 --> 09:49.160]  required to build the Wix, to use Wix to build the MSI. So I'm just going to paste it
[09:49.780 --> 09:54.680]  and just extract that one directory into the downloads directory.
[09:56.060 --> 10:01.400]  Okay, so I can see it here. And let me go into it.
[10:02.260 --> 10:08.100]  And I'll just quickly show you guys all the scripts here. We have a number of different
[10:08.100 --> 10:14.100]  scripts. And what we want to do is we want to build in this case, a customized version
[10:14.660 --> 10:21.300]  of our MSI that already embeds our special configuration. So that MSI will be used can
[10:21.300 --> 10:28.050]  be used to then deploy using any number of software management tools like
[10:30.450 --> 10:39.510]  Group Policy or SCCM or anything like that. So in order for these scripts to work,
[10:39.510 --> 10:47.830]  I need to create a directory called output and copy into it the binary that I want to deploy,
[10:47.830 --> 10:55.790]  which would be the Windows binary. I'll put and call it velociraptor.exe.
[10:55.790 --> 11:01.530]  Okay, additionally, I want to copy the client configuration
[11:02.830 --> 11:10.410]  into the output directory as well. So now I have two files in the output directory.
[11:10.410 --> 11:15.810]  And these two files will be packaged. That's really all it is that's required to be packaged
[11:16.350 --> 11:25.170]  in the MSI. So I'm just going to run the build custom script to create the custom MSI for me.
[11:25.790 --> 11:33.070]  And all it does is it simply runs the Wix tool set with the right scripts and options
[11:33.070 --> 11:41.210]  to just build the MSI. It's going to take a second and it will just create an MSI that I can then use.
[11:43.610 --> 11:55.950]  Okay, so okay, now if I have a look, there is custom MSI here ready for me to build,
[11:55.950 --> 12:00.250]  to deploy. So I'm just going to install it on my machine here.
[12:02.810 --> 12:10.270]  And it will just install Velociraptor and it's ready to go. Okay, so that's all it took.
[12:10.370 --> 12:13.970]  And if we have a look at it over here, and we should be able to see the client
[12:14.910 --> 12:19.750]  already checking in. So it's installed it on this machine and checked into that
[12:20.510 --> 12:24.990]  Debian machine in the cloud that's running the server. So that is really all that's required
[12:24.990 --> 12:31.230]  to deploy Velociraptor client and server. So now I would actually just take that MSI
[12:31.230 --> 12:36.870]  and deploy it across the fleet and get all the endpoints. So that's great. So we've actually
[12:36.870 --> 12:43.390]  managed to install Velociraptor in a few minutes with a proper SSL certificate,
[12:44.150 --> 12:50.770]  automatic DynDNS setup, and it's ready to go. We've seen all the clients.
[12:50.770 --> 12:58.430]  And now what can we do with these clients? So let me just give you guys a quick introduction
[12:58.430 --> 13:06.310]  to the UI. Okay, so when you first go to the Velociraptor UI, you will see the dashboard.
[13:06.890 --> 13:10.010]  Over here on the left side, you can see the number of different options
[13:10.650 --> 13:20.070]  of the different screens of the UI. The home screen is just a dashboard that tells you a
[13:20.070 --> 13:26.570]  of the server. You can see how many connected clients there are. And over here, you can see
[13:26.570 --> 13:35.050]  all the GUI users that are currently configured and what kind of roles they have. You can see
[13:35.050 --> 13:41.370]  that I only created one user called administrator. I can create other ones. And then over here,
[13:41.370 --> 13:47.130]  we can see there is a server version with the version of the server that's currently running.
[13:48.410 --> 13:55.190]  So that's great. Normally, when I would use Velociraptor, I might want to look at a specific
[13:55.190 --> 14:01.770]  endpoint. So I would usually search for it. And over here, there's a search box. I can use
[14:02.930 --> 14:11.990]  the host name. You can see that it has some kind of completion going on here. Or I can actually
[14:11.990 --> 14:19.210]  label machines. You can see I can take this machine and create a label. And let's say I call
[14:19.210 --> 14:26.950]  it test. The label can be anything, but it simply adds the label to that machine. So now it's called
[14:26.950 --> 14:35.050]  test. Now I can actually search for label test. And labels are useful later on when we do hunting
[14:35.050 --> 14:41.870]  and so on. We can select specific labels. So once we search for a machine that we want to look at,
[14:41.990 --> 14:48.050]  in more detail, we can just click on it. And this is just an overview screen to show us
[14:48.710 --> 14:55.750]  what this machine is all about. This is a Windows server data center machine. And then we've got
[14:55.750 --> 15:01.250]  some basic information about it. In this screen, probably the most important thing is the agent
[15:01.250 --> 15:08.970]  version and when it was last seen and the last IP address that we've seen coming from that machine.
[15:08.970 --> 15:15.830]  If we click over to the drill down page, then we can see more details about it,
[15:15.830 --> 15:22.630]  about the machine. You can see more information about the platform and all that sort of stuff.
[15:22.630 --> 15:29.870]  But this is probably a more interesting thing. It shows us the footprint of the agent on the
[15:29.870 --> 15:38.210]  endpoint. So we can see that it takes like 35, around 35 megabytes of memory. And
[15:38.210 --> 15:43.990]  the CPU load is virtually zero because the agent's not really doing anything.
[15:44.030 --> 15:48.470]  So when we do some heavy hunting and we might actually do a lot more work on the machine
[15:49.210 --> 15:54.210]  on the endpoint, then it's useful to see how much memory we're actually using and how much
[15:54.210 --> 16:00.830]  impact we're having on the endpoints. And then this particular one shows us also
[16:01.700 --> 16:07.350]  the users that exist on the endpoints. But this is just kind of an overview
[16:07.950 --> 16:11.450]  information about it. We always collect telemetry so you can always see
[16:12.190 --> 16:19.430]  the most recent telemetry from the endpoint about footprint and so on. The next tab over
[16:19.430 --> 16:25.870]  shows us the interactive shell. This is an easy UI that allows us to just create,
[16:25.870 --> 16:31.150]  just run shell commands on the machine. We try generally not to run too many shell commands
[16:31.150 --> 16:36.890]  because they can be unpredictable, but it's possible to just break into a shell.
[16:37.070 --> 16:42.690]  Over here we've got a number of different options. We can run our shell commands through PowerShell
[16:42.690 --> 16:49.210]  or CommandShell or Bash. Usually I would prefer to run with PowerShell because it's just a little
[16:49.210 --> 16:58.310]  more reliable with regards to escaping quotes and stuff like that. So here's an example,
[16:58.310 --> 17:06.330]  ipconfig slash all examples will show us everything about the interface.
[17:06.330 --> 17:12.010]  You can see that over here, this is the time and who ran the command. So when you have multiple
[17:12.010 --> 17:18.790]  users, you can see who actually issued this shell command. And over here we have kind of a little
[17:18.790 --> 17:25.910]  bit of a UI here that kind of hides the results a little bit. When you have many shell commands,
[17:25.910 --> 17:33.850]  then it's easy to see, it's really easy to lose it. So it allows you to kind of hide them a little
[17:33.850 --> 17:40.170]  bit. And this one just kind of hides them inside of a kind of indented cell. So it's just the UI
[17:40.170 --> 17:49.450]  kind of feature. But we can essentially type something else, google.com,
[17:49.450 --> 17:54.750]  and then run it. And you'll see that this spinner will just wait while the command is running.
[17:55.470 --> 18:00.090]  And then when they complete, we will see the results. So we can see that
[18:00.090 --> 18:07.770]  the results. So this is kind of handy when you have to do interactively look at the machine.
[18:10.170 --> 18:18.110]  The next one over is the VFS. The VFS is a way for us to interactively examine the machine,
[18:18.110 --> 18:25.610]  the machine's file system. So over here we have these are accesses, different types of things
[18:25.610 --> 18:32.090]  that we can look at. And what we're looking at here is really just the server's cache of
[18:33.590 --> 18:40.910]  what the file system sort of looks like. But it isn't just checking the file system on the
[18:40.910 --> 18:47.830]  endpoint. It's just what it already knows about. So when you navigate to a directory that hasn't
[18:47.830 --> 18:53.030]  been listed before, then it doesn't know about it. And it tells you no data available for this
[18:53.030 --> 18:59.590]  directory. So initially, there will be no data available. So you can click on this button here
[18:59.590 --> 19:06.910]  to refresh the directory. And what it will do is it will just issue a directory refresh query to
[19:06.910 --> 19:13.470]  the endpoint and just list the directory, and then refresh the server's view of it.
[19:13.650 --> 19:19.310]  So you can sort of go through and click and refresh, click and refresh. Or you can simply
[19:19.310 --> 19:27.730]  just do this recursive refresh, and it just goes off. And it takes a little bit longer,
[19:27.730 --> 19:36.090]  but it just recursively refreshes all the subdirectories. So you can kind of look through
[19:36.090 --> 19:42.750]  them without having to click all the time. So this is a bit of a UI thing. And for example,
[19:42.750 --> 19:50.950]  if we have a look at our files, we can have... for instance, you would know that there is an
[19:50.950 --> 20:01.710]  ntuser.dat in the user's home directory. And we don't actually have the data, we just know about
[20:01.710 --> 20:07.030]  it. So we listed the directory. And if we actually want to see that file, then we can fetch that file
[20:07.030 --> 20:12.650]  specifically from the endpoint. So we can just click on this thing, and it goes off and fetches
[20:12.650 --> 20:19.190]  it. And then we'll have a little icon here, which is, you know, just indicates that the server has
[20:19.270 --> 20:24.890]  a copy of that file now. So we're able to see it from the server, and we can also download it and
[20:25.430 --> 20:31.550]  things like that. And for those of you who know, you would have seen that typically the ntuser.dat
[20:31.550 --> 20:38.310]  is locked when a user is logged in, but Velociraptor will fall back to raw NTFS parsing
[20:38.930 --> 20:44.870]  in case it's locked. So it will actually retrieve the data, even if it's locked. And you can see
[20:44.870 --> 20:53.550]  hex view and so on. So that's essentially the VFS view, which is the virtual file system.
[20:53.750 --> 20:59.530]  And it's just a view over in the NTFS. I think we can actually see
[21:01.030 --> 21:06.430]  what it looks like in a raw NTFS parser. So we can see all those hidden files
[21:06.430 --> 21:11.190]  like the MFD, and we can collect the MFD in exactly the same way as we did before
[21:12.050 --> 21:19.990]  from the server, just by pressing this button. MFD is somewhat larger,
[21:19.990 --> 21:26.610]  so it's going to take a little bit longer. Okay, so the question is, what are we doing
[21:26.610 --> 21:32.330]  when we're pressing these GUI buttons? And we can essentially just look at it in the same way
[21:32.810 --> 21:38.610]  and download it and so forth. So you might wonder what is actually happening here
[21:39.060 --> 21:47.230]  with the Velociraptor endpoints? Well, Velociraptor is really a VQL engine. It just
[21:47.230 --> 21:54.950]  runs these query languages. VQL is the query language that runs the entire Velociraptor
[21:54.950 --> 22:02.670]  architecture. When we click on the UI, what we're doing is we're issuing VQL queries
[22:02.670 --> 22:06.860]  on the endpoints. We're just issuing different kinds of queries.
[22:08.070 --> 22:15.090]  And so if we go back to our overview here, then we have the Collector tab.
[22:15.810 --> 22:19.820]  And this Collector tab shows us all the artifacts that we've collected.
[22:20.250 --> 22:29.590]  So an artifact is simply a VQL query. So every time we click through the UI
[22:29.590 --> 22:36.130]  behind the scenes, the UI simply issues a different kind of artifact to collect from
[22:36.130 --> 22:42.890]  the endpoints. In other words, it just simply issues different kinds of VQL queries. And you
[22:42.890 --> 22:50.050]  can see that by simply looking at the Request tab. The Request tab is showing us all the raw
[22:50.050 --> 22:58.450]  requests that is going out to each endpoint. And we can see over here, queries. This is the VQL
[22:58.450 --> 23:03.790]  queries that are going out. So really, whenever we talk to the endpoint, all we're doing is sending
[23:03.790 --> 23:13.370]  VQL queries to the endpoint. And that's basically all it is. So for instance, here, when we ran the
[23:13.370 --> 23:18.570]  PowerShell, we're looking at different PowerShell and we can see, you know, we sent a command,
[23:18.570 --> 23:26.730]  that was the query, and so on. Let's have a look. So when the query is going to the endpoint,
[23:26.730 --> 23:32.550]  then it will execute on the endpoint. And the next tab that's interesting is the query log.
[23:32.550 --> 23:37.690]  So as the query is executing on the endpoint, the endpoint is logging some interesting
[23:38.430 --> 23:44.670]  things about the query, so like errors or anything like that. So we can see over here,
[23:44.670 --> 23:52.530]  that as the query is running, we get logs. And then finally, it tells us how many rows
[23:52.530 --> 23:58.130]  the query is returning, because ultimately, all queries just return rows, because, you know,
[23:58.130 --> 24:05.570]  it's just a query. So the results tab simply shows us the rows that are returned for each query.
[24:05.570 --> 24:12.890]  In this case, when we ran the PowerShell, it just returns a row and has a column called std out,
[24:12.890 --> 24:18.130]  and then std error and the return code. Over here, when we listed the directory,
[24:18.860 --> 24:26.350]  it has a bigger query, and it returns more rows and more columns. But ultimately,
[24:26.350 --> 24:32.130]  it's still the same. It's just a table. Everything we do is just a table that's returning.
[24:32.810 --> 24:41.510]  All the queries are simply tables. So we looked at the VFS UI, and it's kind of a nice UI. It's
[24:41.510 --> 24:48.010]  intuitive, and it's kind of what we're used to when we look at, you know, Windows Explorer,
[24:48.010 --> 24:53.090]  something like that, people quite understand this sort of file system hierarchy. But we've
[24:53.090 --> 24:57.590]  seen that it actually just creates artifact collections in the background, but we can
[24:57.590 --> 25:03.090]  actually just collect other artifacts. So if we click on this plus button here,
[25:03.090 --> 25:09.410]  we will collect a new artifact. And over here, we have a search screen. So we can search for
[25:09.710 --> 25:19.270]  a number of different kind of artifacts. For example, a prefetch artifact. So as you know,
[25:19.270 --> 25:28.530]  prefetch is a set of files that are stored in the Windows prefetch folder, and they maintain
[25:29.590 --> 25:35.810]  a list of information about executables that are typically run. But one of the cool things about
[25:35.810 --> 25:45.070]  them is that they actually maintain a timeline of each executable when it was run. So it's often
[25:45.070 --> 25:52.770]  useful to build a timeline based on the prefetch information, because then we will be able to
[25:53.850 --> 25:59.390]  pinpoint when a particular binary was run, which might be useful for a GFIR investigation.
[25:59.390 --> 26:08.610]  So we can choose the prefetch artifact. And we can see that the artifact gives us a bit
[26:08.610 --> 26:14.510]  of an explanation about what it is that it's doing, a little bit of background information,
[26:14.510 --> 26:20.810]  then it can take a bunch of parameters. And over here, we can see this is the PQL source
[26:20.810 --> 26:25.810]  that's actually going to run. So we can look at it. But we don't really need to kind of understand
[26:25.810 --> 26:30.770]  it too much. If we want to collect this, we simply click add. And then we will fold that
[26:30.770 --> 26:37.810]  top pane up. So that will give us access to all the parameters that we can configure.
[26:38.450 --> 26:45.310]  And the parameters are actually then used to control the query, the VQL query,
[26:45.310 --> 26:51.130]  or by the artifact. But you know, here we can, this particular artifact allows us to filter by
[26:52.050 --> 26:57.370]  timestamps or, you know, or binary regular expressions or other things like this.
[26:58.830 --> 27:05.550]  So, but we're just going to just run it, but usually the defaults do kind of the right thing.
[27:05.630 --> 27:11.770]  So when we run it, it will immediately issue that collection and collect that from the endpoint.
[27:12.290 --> 27:19.090]  Right? So it basically goes off and builds a timeline from the prefetch data. So every time
[27:19.090 --> 27:26.510]  we run a binary, it has some, some timing here. So this is really great, right? We basically can,
[27:26.510 --> 27:32.430]  can see what, what the results are. Right? Another very interesting one is to look for
[27:32.430 --> 27:42.790]  scheduled tasks, scheduled tasks, because that's a pretty common, a pretty common persistence
[27:42.790 --> 27:49.070]  mechanism. And then, you know, all we have to do is simply click add and then just launch it.
[27:49.750 --> 27:56.990]  And off we go. It just, it goes off and calculates it and take a couple of seconds and do that.
[27:57.770 --> 28:01.990]  Okay. And then we have the results here. So this is basically how we would collect
[28:02.930 --> 28:07.130]  a bunch of information. Right?
[28:10.130 --> 28:14.930]  So, so far it was kind of nice. We collected specific information from the endpoint
[28:14.930 --> 28:21.550]  about prefetch, about task scheduler, et cetera. What if we wanted to collect it from all our
[28:21.550 --> 28:27.190]  machines at once? We have, I mean, in this case, we only have one machine connected to this
[28:27.190 --> 28:32.470]  deployment, but typically we might have say 10,000 endpoints connected to the deployment.
[28:33.010 --> 28:39.070]  When we want to collect the same artifact from many machines at once, we call this a hunt. And
[28:39.070 --> 28:45.530]  over here we have the hunt manager, which is exactly the same idea, except it just automatically
[28:45.530 --> 28:52.750]  collects it from all the machines that are connected at once. So we have a similar GUI,
[28:52.750 --> 28:59.470]  very similar UI to before, right? Except now we're doing it in a hunt. So let's just say that we
[28:59.470 --> 29:06.850]  wanted to find all the information about running processes. So we wanted to use PSLIST as a hunt.
[29:06.850 --> 29:14.250]  So we just choose add, and again, we can configure it somehow and see that we can
[29:14.250 --> 29:21.710]  do a regular expression for which processes we want to look at and so on. But this time,
[29:21.710 --> 29:28.190]  hunt has an expiry. What this means is that once we start this hunt, it will just continue running
[29:28.190 --> 29:34.470]  until the expiry time. And anytime a new machine comes back online and connects to our endpoint,
[29:34.470 --> 29:40.190]  it will pick that collection up and it will just run it. So we don't have to
[29:40.930 --> 29:47.350]  catch the machine when it's on. Basically, we just schedule it and it will just run it when
[29:47.350 --> 29:58.090]  the machine comes online in its convenience, right? So we click next. We can specify description,
[29:58.730 --> 30:02.270]  process listing, let's say.
[30:03.830 --> 30:11.970]  Next. And here we can choose to run it everywhere or just choose the right labels. If you recall
[30:11.970 --> 30:17.410]  before, we created the label before. We'll test. We can simply restrict it to all those machines
[30:17.410 --> 30:25.130]  that have that label or run everywhere. And run everywhere will assign the hunt to all the
[30:25.130 --> 30:30.930]  machines. So we click next. Now it's showing us this is going to be the request. This is what
[30:30.930 --> 30:38.430]  we're going to be sending. Looks good. Let's go. When we create the hunt, it's created in a paused
[30:38.430 --> 30:47.230]  state. So it's not actually running yet. We click start to actually start it. And off it goes.
[30:47.310 --> 30:52.130]  As soon as we click start, it schedules it to all the machines that are currently connected.
[30:52.130 --> 31:03.510]  So far, it's only got one machine. And it's finished. So as soon as the machines will finish,
[31:03.510 --> 31:09.510]  it essentially creates that. We can have a look at all the clients that are connected. There's
[31:09.510 --> 31:16.370]  really only one in this case, but there could be many more. The status tab shows us if there's
[31:16.370 --> 31:22.190]  any errors. And over here, we can see the results of the hunt.
[31:23.410 --> 31:27.990]  So over here, we can see this is a process listing of this machine.
[31:30.630 --> 31:38.690]  If we wanted to process this data using another tool, then we simply need to prepare a download
[31:38.690 --> 31:45.450]  over here. And it will create a zip file that contains all of the information in this hunt from
[31:45.450 --> 31:50.570]  all the machines. Let's take a look. What does the zip file look like? This is only going to be
[31:50.710 --> 31:57.070]  a small one because it's really only the one machine. But we're going to see a CSV and adjacent
[31:57.070 --> 32:04.990]  file of all of the results combined from all the machines. And as well as that, we actually have
[32:05.570 --> 32:13.010]  the collection split up for each machine. These are the logs. And these are the artifacts that
[32:13.010 --> 32:18.510]  we ended up collecting as part of these hunts. So that sort of split up individually and combined.
[32:19.470 --> 32:25.790]  And also, if any of these hunts collect files, then we will be able to get that in the zip as
[32:25.790 --> 32:34.210]  well. So this is just a way that we can use to export data. Now over here, you can see that
[32:34.210 --> 32:40.570]  it's still kind of in the running state. And some people are confused by that. But this is just,
[32:40.570 --> 32:47.150]  that hunts always run, they simply expire. So when we created until the expiry time,
[32:47.150 --> 32:52.270]  when we started till the expiry time, for that time period, it will be active, and then it will
[32:52.270 --> 32:58.610]  become stopped by itself. And it will no stop means that it no longer accepts new
[32:59.070 --> 33:05.010]  new clients that come online at that time. So that's, that's basically hunts.
[33:06.210 --> 33:11.270]  Okay, so that's, that's pretty cool. We can see how we can export the data and use it in another
[33:11.270 --> 33:19.030]  tool. Sometimes, we really want to be able to post process the data within the tool within
[33:19.030 --> 33:28.270]  FlossRaptor. So the next feature I wanted to show you guys is the notebook feature.
[33:28.270 --> 33:37.470]  Notebook is basically like a collaborative analyst tool that we can use to, to analyze
[33:38.080 --> 33:43.580]  the results from a particular investigation, put them together and post process them.
[33:43.950 --> 33:50.970]  So I'm just going to show you quickly how I would build a notebook. So I would click this plus
[33:50.970 --> 33:57.990]  button here, which creates a new notebook. And I can call it whatever I want, like test notebook,
[33:57.990 --> 34:05.490]  for example, give it some description. And here I can choose collaborators that I would
[34:05.490 --> 34:10.830]  like to collaborate. So it's like a collaborating, you know, a Google Doc or something like that is
[34:10.830 --> 34:19.310]  it's very pretty familiar concept. When I submit it, it will create a new notebook over here. And,
[34:19.310 --> 34:25.010]  and you'll see that down here we have the title will be copied into here. So that over here,
[34:25.010 --> 34:29.530]  we can see all the notebooks that I currently have. And when I click over here, I have to
[34:29.530 --> 34:36.450]  actually click on the title itself to bring it into focus. And I will see that it creates,
[34:36.450 --> 34:42.850]  this is called a cell. So a notebook is consisting of different cells. And over here, again,
[34:42.850 --> 34:49.630]  this is called a markdown cells. You can see its type is markdown. So I can simply use,
[34:49.630 --> 34:54.850]  just describe this. And normally I would put like some background for the investigation.
[34:55.450 --> 35:06.030]  Demo cell for demo. Right. And I actually can also copy paste, copy image,
[35:06.030 --> 35:10.070]  take a screenshot. I can actually paste the image in here.
[35:11.650 --> 35:17.010]  Right. And this is just markdown. If you're familiar with the markdown, it's very, very
[35:17.010 --> 35:23.550]  familiar. When we save it, it simply renders it. So it's just a markdown here where I can put some
[35:23.550 --> 35:29.650]  notes. So that's not the most interesting thing, but let's say that I wanted to do more
[35:30.350 --> 35:36.870]  interesting post-processing. Well, I can create another cell and add it from a particular flow
[35:36.870 --> 35:44.590]  or hunt that I've created previously. So from a particular collection. So let's just add cell
[35:44.590 --> 35:52.150]  from flow. I choose the client and these are the flows that ran before. Right. So here I've got my
[35:52.150 --> 36:00.510]  task schedule, for instance. So all this does is it creates VQL. It pre-fills the VQL for me with
[36:00.510 --> 36:08.750]  the right cell IDs and all this sort of stuff. This is simply a VQL query that just post-processes
[36:08.750 --> 36:12.150]  the information that we've already collected. So it doesn't go out to the client and collect
[36:12.150 --> 36:20.130]  the information again. It just post-processes it. It's useful in order for us to see,
[36:21.090 --> 36:26.930]  to be able to post-process it and filter it and so on. So for instance, in this particular case,
[36:26.930 --> 36:32.690]  we are looking at task schedule and this task scheduler. And, you know, maybe a particular
[36:34.030 --> 36:43.030]  malicious task would have maybe PowerShell. We wanted to know which tasks are running
[36:44.670 --> 36:50.110]  PowerShell. So this one will return all the tasks. And now we would like to filter it.
[36:50.130 --> 36:57.490]  Where commands, and this is the regular expression operator,
[36:57.490 --> 37:05.730]  matches PowerShell. Okay. And then if I press save, okay, there's no PowerShell here.
[37:08.070 --> 37:25.030]  Okay. So we have Google update or whatever. So you can basically run DLL is a common,
[37:25.030 --> 37:34.130]  this machine is not actually owned, but is not compromised, but so you can see it. So here,
[37:34.130 --> 37:39.430]  for example, we can filter by run DLL, see all the, all the commands that have run DLL.
[37:39.570 --> 37:45.850]  So this allows us to do these post-processing kind of operations. We can do the same thing,
[37:45.850 --> 37:53.750]  add cell from hunt and looking at our process listing hunt, same thing. It simply creates
[37:53.750 --> 38:01.950]  the table for us, the query for us initially, right? So for instance, we can say where,
[38:07.320 --> 38:16.200]  where name matches Velociraptor to see all the Velociraptor processes that are running.
[38:16.200 --> 38:21.200]  We can see there it is. The Velociraptor process is running. That's the hashes.
[38:21.200 --> 38:26.860]  That's the authentic code information. Is it signed? Yes, it is. And so on. So we can get
[38:26.860 --> 38:32.780]  this kind of high level information and the username is running it as a system. So this is
[38:32.900 --> 38:42.020]  a pretty cool, cool way of post-processing the different, different things. So I'm not going to
[38:42.020 --> 38:48.380]  get into too much into the, the artifacts and how to actually write the QL, but as a process to say
[38:48.380 --> 38:54.760]  that in this screen here, we can view all the different artifacts and let's just reiterate
[38:54.760 --> 39:03.340]  again, what an artifact is. As I said Velociraptor simply runs VQL, but if the UI simply required you
[39:03.340 --> 39:09.020]  to type a new query each time, and that would be very tedious and error prone, and it would just
[39:09.020 --> 39:15.740]  not be a very good user experience. So with Velociraptor, we have a concept of artifacts
[39:15.740 --> 39:26.080]  and artifact is simply a YAML file that contains the descriptions behind the particular VQL and
[39:26.080 --> 39:35.260]  the VQL itself. So let's have a look at something like, let's say the DNS, DNS cache. This is an
[39:35.260 --> 39:42.040]  example of a, of an artifact. And you can see that here in this screen, we can view all the
[39:42.040 --> 39:46.960]  different artifacts and we can actually edit them as well. So this particular artifact,
[39:46.960 --> 39:53.540]  you can see that it has some VQL here. It just queries the DNS cache on a Windows system.
[39:53.780 --> 40:02.080]  So we have some explanation of what it does, and then it just, it just does it right. So,
[40:02.580 --> 40:12.020]  so let's have a look at what does it look like in, we said it's a YAML file. So if we click the,
[40:12.020 --> 40:17.340]  to edit it a little bit. And so you can see that we can customize using this UI,
[40:17.340 --> 40:24.720]  we can customize the artifact. So we can simply add in here, the, the different,
[40:24.720 --> 40:30.300]  different things, right? So, you know, we could say, Oh, okay. You know, if we, maybe we wanted
[40:30.300 --> 40:40.100]  to add a filter or something else, we can simply, we can change this as required or write our own.
[40:40.100 --> 40:46.700]  And so we can go over here for instance, and let's open a new tab.
[40:51.760 --> 41:04.870]  Collected cache. Okay. Let's collect the DNS cache again. And it's very quick to do, to do that.
[41:04.870 --> 41:11.390]  As soon as we ask to collect it, it will, it will essentially do it instantly. It goes out to the
[41:11.390 --> 41:17.710]  end point and collects it instantly. And we can see all the different, all the different DNS names
[41:17.710 --> 41:24.710]  that are in cache at the moment. So hopefully this was a quick, short introduction to Velociraptor.
[41:24.710 --> 41:30.830]  We went through the installation process, which only took a couple of minutes. And then we went
[41:30.830 --> 41:38.870]  through some of the things that we can do with it. Again, the sky's the limit, really. We can
[41:38.870 --> 41:43.850]  collect different things and we would normally respond to the different incidents and collect,
[41:44.990 --> 41:53.690]  you know, connect different artifacts to, you know, all the time. But, you know, it's,
[41:53.690 --> 42:01.150]  it's just a very powerful tool that allows us to gain unprecedented visibility of the endpoints
[42:01.670 --> 42:07.810]  that we really can't get with other tools currently. Okay. Thanks for watching.
[42:09.730 --> 42:15.750]  And yeah, if you're interested in Velociraptor, have a look, go to the GitHub
[42:15.750 --> 42:21.450]  and download it. It's open source. And also contribute and join our community.
[42:22.050 --> 42:26.210]  Thanks again for listening. Thanks.
